Skip to content

build: add optional hardened production flags#1138

Open
PR9000 wants to merge 1 commit into
DeusData:mainfrom
PR9000:freebsd-hardening
Open

build: add optional hardened production flags#1138
PR9000 wants to merge 1 commit into
DeusData:mainfrom
PR9000:freebsd-hardening

Conversation

@PR9000

@PR9000 PR9000 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Add an optional, non-intrusive production hardening option in Makefile.cbm.

This change was prepared alongside PR #1093 (fix(foundation): use HW_PHYSMEM for physical memory detection on FreeBSD), but was split into a separate PR to keep the scope focused.

The new FREEBSD_HARDENING option supports hardened downstream packaging environments (for example, FreeBSD Ports Collection).

Details

When enabled via FREEBSD_HARDENING=1, production builds (cbm and cbm-with-ui) receive:

  • Stack protection: -fstack-protector-strong
  • Fortify source definition: -D_FORTIFY_SOURCE=2
  • Linker hardening options: -Wl,-z,relro -Wl,-z,now

The implementation keeps upstream impact minimal:

  • It is strictly opt-in (default is 0), so existing builds, CI pipelines, and developer workflows are unchanged.
  • It only affects production targets through CFLAGS_PROD, CXXFLAGS_PROD, and LDFLAGS.
  • Test builds remain unchanged, avoiding interaction with ASan/UBSan/TSan configurations.
  • The hardening flags are separated into generic HARDEN_CFLAGS and HARDEN_LDFLAGS variables to keep the build logic portable.

Verified this locally on FreeBSD 15.1:

gmake -f Makefile.cbm clean-c
gmake -f Makefile.cbm cbm FREEBSD_HARDENING=1
gmake -f Makefile.cbm cbm-with-ui FREEBSD_HARDENING=1

The resulting ELF binary was verified with:

readelf -d build/c/codebase-memory-mcp | grep BIND_NOW
readelf -d build/c/codebase-memory-mcp-with-ui | grep BIND_NOW

Output:

codebase-memory-mcp:
0x000000000000001e (FLAGS)        BIND_NOW

codebase-memory-mcp-with-ui:
0x000000000000001e (FLAGS)        BIND_NOW

and:

readelf -l build/c/codebase-memory-mcp | grep GNU_RELRO
readelf -l build/c/codebase-memory-mcp-with-ui | grep GNU_RELRO

Output:

codebase-memory-mcp:
GNU_RELRO      0x117164e0 0x00000000119184e0 0x00000000119184e0 0x000b40 0x001b20 R   0x1

codebase-memory-mcp-with-ui:
GNU_RELRO      0x1185f5e0 0x0000000011a615e0 0x0000000011a615e0 0x000b50 0x001a20 R   0x1

Both production targets were verified successfully with the hardening option enabled.

Checklist

  • Every commit is signed off (git commit -s) — required, CI rejects
    unsigned commits (DCO, see CONTRIBUTING.md)
  • Tests pass locally (make -f Makefile.cbm test)
  • Lint passes (make -f Makefile.cbm lint-ci)
  • New behavior is covered by a test (reproduce-first for bug fixes)

@PR9000
build: add optional hardened production flags
0dad34d 
Signed-off-by: Pedro Ramos <131530838+pr9000@users.noreply.github.com>
@PR9000
PR9000 requested a review from DeusData as a code owner July 16, 2026 17:08
@PR9000

PR9000 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Hi @DeusData,

It looks like this PR is currently blocked by the security / codeql-gate check rather than by the changes themselves.

From the workflow logs, the gate waits for the separate CodeQL workflow to complete, but the CodeQL run remained in_progress until the 45-minute timeout expired:

Waiting for CodeQL to complete...
...
BLOCKED: CodeQL timeout

All other checks completed successfully.

Would you mind re-running the CodeQL workflow (or the failed checks) for this PR?

Thank you!

@DeusData DeusData added enhancement New feature or request security Security vulnerabilities, hardening priority/normal Standard review queue; useful PR with ordinary maintainer urgency. labels Jul 18, 2026
@DeusData DeusData added this to the 0.9.2-rc milestone Jul 18, 2026
@DeusData

DeusData commented Jul 18, 2026

Copy link
Copy Markdown
Owner

Thanks for flagging the earlier timeout. The CodeQL workflow recovered without intervention and every check on exact head 0dad34dc924a22d4d3da3bb9eb2d93933a1ef3ad is now green, so no rerun is needed.

For the build direction, we do want production hardening, but not as a permanent FreeBSD-specific opt-in that leaves the standard release artifacts unchanged. Please rework this into a generic production-hardening policy: use platform/compiler capability rather than a FreeBSD name, enable the supported stack-protector, FORTIFY, RELRO, and immediate-binding protections by default for compatible ELF production builds, retain an explicit escape hatch for incompatible downstream toolchains, and leave sanitizer/test builds unchanged. The verification should inspect the produced standard artifacts for a non-executable stack, RELRO, and BIND_NOW where applicable. Keep this PR limited to that build policy; no unrelated build-system changes.

@PR9000

PR9000 commented Jul 18, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the detailed feedback. I'm glad to hear the goal of enabling production hardening aligns with the project's direction.

My original FREEBSD_HARDENING option was intended only to support downstream packaging (specifically the FreeBSD Ports Collection) without introducing any behavior changes for existing users or CI. I don't have enough familiarity with the full compiler/platform matrix supported by the project to confidently generalize it without guidance.

Reworking this into a generic PRODUCTION_HARDENING ?= 1 policy makes sense. Before I do that, could you clarify two points?

  1. Should the initial implementation target only ELF platforms (Linux, *BSD) where these hardening features are standard, leaving macOS (Mach-O) and Windows (PE) unchanged for now?

  2. Would you prefer compiler/linker capability detection (probing supported flags), or should I build on the project's existing platform/compiler detection logic?

Once I understand the intended scope, I'll rework the Makefile accordingly and keep this PR focused on the production hardening policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@DeusData DeusData Awaiting requested review from DeusData DeusData is a code owner

Assignees

No one assigned

Labels

enhancement New feature or request priority/normal Standard review queue; useful PR with ordinary maintainer urgency. security Security vulnerabilities, hardening

Projects

None yet

Milestone

0.9.2-rc

Development

Successfully merging this pull request may close these issues.

2 participants

@PR9000 @DeusData